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ABSTRACT 

We apply the principles of the intersection type discipline to the 
study of class-based object oriented programs and; our work fol- 
lows from a similar approach (in the context of Abadi and Cardelli's 
g-object calculus) taken by van Bakel and de'Liguoro. We define 
an extension of Featherweight Java, pFJ, and present a predicate 
system which we show to be sound and expressive. We also show 
that our system provides a semantic underpinning for the object ori- 
ented paradigm by generalising the concept of approximant from 
the Lambda Calculus and demonstrating an approximation result: 
all expressions to which we can assign a predicate have an approx- 
imant that satisfies the same predicate. Crucial to this result is the 
notion of predicate language, which associates a family of predi- 
cates with a class. 

1. INTRODUCTION 

It was only after the introduction of object oriented programming 
that attempts were made to place it on the same theoretical foun- 
dations as functional programming. The first were based around 
extending the Lambda Calculus (A-calculus) (9) and representing 
objects as records 1131 1331 1141 1221 . The seminal work of Abadi 
and Cardelli |1] constitutes perhaps the most comprehensive for- 
mal treatment of object orientation, and introduces the c;-calculus, 
which formalises the object-based programming paradigm. Similar 
formal models describing class-based languages have been devel- 
oped as well; notable efforts are Featherweight Java 126 1 and its 
successor Middleweight Java 1121 . 

An integral aspect of the theory of programming languages is 
type theory which allows for static analysis via abstract reasoning 
about programs, so that certain guarantees can be given about their 
behaviour. Type theory easily found acceptance within the world 
of programming, not only through Milner's claim "typed programs 
cannot go wrong'Q but also because static, compile time type anal- 
ysis allows for efficient code generation, and the generation of effi- 
cient code. The quest for expressive type systems is still ongoing; 
for example, types with quantifiers 1 23 . 36 1 as investigated in the 



'Here 'wrong' is a semantic value that represents an error state, 
created when, for example, trying to apply a number to a number. 
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early nineties 132113411351 115 1, and the intersection type discipline 
(ITD), as first developed in the early 1980s [17] HU QUI are two 
good examples of systems which, while undecidable in principle, 
have found practical application. 

ITD generalises Curry's system by allowing more than one type 
for free and bound variables, grouped in intersections via the type 
constructor n. By introducing this extension a system is obtained 
that is closed under /3-equality: if B h M : a and M N, then 
B h N : a, making type assignment undecidable. Intersection sys- 
tems satisfy a number of strong properties that are preserved even 
when considering decidable restrictions. For example, soundness 
(subject reduction) will always hold, as does the fact that a term that 
satisfies certain criteria will terminate (has a normal form), or, with 
different criteria, produce output (has a head-normal form). The 
strength of ITD motivated de'Liguoro 1 19 1 to apply the principles 
of intersection types to object oriented programming, in particular 
to the Varsigma Calculus. Over three papers (5][(j][7), several sys- 
tems were explored, for various variants of that calculus. In this 
work, we aim to follow up on these efforts and apply the principles 
of intersection types, and the system of |7 1 specifically, to a formal 
model of class-based object oriented programming; the model we 
use is based on |26|. Having defined the calculus, we will then 
prove a subject reduction result. 

The goal of our research is to come to a semantics-based or type- 
based abstract interpretation for object orientation, for which the 
present paper contains the first steps. To be exact, we show the 
approximation result: any non-trivial predicate assignment for an 
expression is also achievable for an approximant of that expres- 
sion, i.e. a finite rooted segment of its head-normal form. Thus we 
link semantics and predicates; the head-normal form is assured to 
exist by the fact that a non-trivial predicate can be assigned. This 
then can be used as a basis for abstract interpretation; an analysis 
that is immediately within reach is that of termination, as we will 
show in this paper. This is certainly not the only one however; one 
could think of dead code analysis, type and effect systems, strict- 
ness analysis, etc. 

While the abstract interpretation of object-oriented languages 
has certainly been an active topic of research, the majority of ap- 
proaches taken thus far appear to have concentrated on control-flow 
and data-flow analysis techniques rather than type-based abstrac- 
tions |31 j; an exception to this is found in |25|. Another obser- 
vation is that work in this area has been centred around issues 
of optimisation: |28| presents a class analysis of object-oriented 
programs which may be used to eliminate virtual function calls, 
pointer analysis [ 37 1 generalises class analysis and also allows for 
the detection of null pointer dereferencing, and other analyses 1291 
1301 have looked at inferring invariants for classes which can be use- 
ful in many optimisations such as the removal of checks for array 



bounds. Termination analysis, missing from this list, is covered 
by our treatment. Such an analysis has been done on Java byte- 
code 1 2], however our system aims at performing such an analysis 
directly at the level of the object-oriented language rather than its 
intermediate form. 

The normal, class-based type system for our variant of Java is 
sound, but not expressive enough to come to in-depth analysis of 
programs; we therefore introduce the additional concept of pred- 
icates, which express the functional behaviour of programs, and 
allow their execution to be traced. We show that the standard (func- 
tional) properties hold and, moreover, put in evidence that we have 
a strong semantic system: we prove an approximation result and 
characterise head-normalisation and termination. The system, be- 
ing semi-decidable at best, would need to be limited in expressive- 
ness before it can be used for static analysis. This notwithstanding, 
the main properties shown in this paper would hold also for such a 
restriction. 

2. PREDICATE FEATHERWEIGHT JAVA 

In this section we define our extension of Featherweight Java 
(FJ), which we call Predicate Featherweight Java (or pFJ). FJ 1 26 1 is 
a minimal (functional) calculus based on Java 1 24 1 which expresses 
the core features of a class-based object oriented programming lan- 
guage (e.g. inheritance, method invocation and field access, object 
creation). Its compact nature allows proofs of its properties to be 
correspondingly succinct. As such, it has proved extremely popu- 
lar as a starting point for formally studying extensions to Java 1271 
1401 12 1 1 1201 1 111 . The treatment of FJ and its variants in the literature 
is very comprehensive, and so here we only define the elements of 
pFJ informally, and discuss its departures from FJ. 

Definition 1. (pF] SYNTAX) The syntax of pFJ is defined by the 
following grammar: 

cd ::= class C extends C' { fd md } (C + Object) 
md ::= Dm(Ci) {e} 
fd ::= Cf 

e ::= x | null | e.f | e.f = e' | e.m(e) | new C(e) 

£C ::= cd 
P :: = (£C,e) 

The meta-variables C and D range over class names (which, as 
in FJ, we also use as types); m ranges over method names, / over 
field identifiers, and x over variable names. The set of class names 
includes the distinguished name Object, and the set of variables 
includes the distinguished name this. 

In a similar notation to that of FJ we use e to represent a possibly 
empty sequence of elements (in this particular case, expressions). 
When necessary, such a sequence may be subscripted with a meta- 
variable indicating the number of elements it contains, e n . Notice 
that elements of a sequence are permitted to be composite, as in 
C x. Sequence concatenation is represented by e ■ e', and e denotes 
the empty sequence. We use n for the set {1, . . . , «}, where n is a 
natural number. 

Definition 2. An execution context is a sequence of class dec- 
larations, and a program is a pair of an execution context and an 
expression to be evaluated. Classes contain a list of fields and a 
list of methods, the (class) types of which must be declared. As 
in FJ, the superclass must always be explicitly declared even if it 
is Object. Methods may take multiple arguments and method 
bodies consist of a single expression. 



We call EC an execution context, rather than a class table, in order 
to highlight its purely syntactic nature (as opposed to some form of 
lookup). 

Notice that pFJ does not explicitly include constructors, as FJ 
does. We have chosen to elide this feature since in FJ it is merely 
'syntactic sugar': constructor methods are never run, in the same 
sense that other methods are invoked, and were included to ensure 
that all valid FJ programs are also valid Java programs. In pFJ, 
we make object constructors implicit by requiring (in the type rule 
for the new keyword) that the types of the expressions that are to 
be assigned as field values match the types for the fields as de- 
fined by the class of the object being created. We also omit the 
return keyword in method bodies for the same reason. We feel 
that this simplifies the calculus without diminishing its relevance in 
any way. 

An important difference between pFJ and FJ is that we omit cast 
expressions in pFJ, which were included in FJ in order to support 
the compilation of Featherweight GJ programs to FJ 1261 §3]. Since 
that is not an objective of our work, and (more importantly) the 
presence of downcasts makes the system unsound in the sense that 
well-typed expressions can reduce to expressions containing mean- 
ingless (or 'stupid') casts, they are omitted. Upcasts are replaced 
by subsumption rules in the type system. In pFl we also include 
syntax to represent the null value and a field assignment oper- 
ation. One of the objectives of our research is to lay a foundation 
for the treatment of a stateful model of object oriented programs, of 
which these two elements are quintessential components. We there- 
fore feel that it behooves us to incorporate them into the model at 
the earliest opportunity. Indeed, even at the functional level, we 
find that their inclusion has some interesting (and non-trivial) con- 
sequences: our predicate system can be made expressive enough 
to catch 'null pointer dereferences', and field assignment has im- 
portant implications for the definition of predicate languages in a 
complete system. 

Definition 3. We use the (syntactic) execution context to define 
a family of standard lookup functions: 

1. F{£C,C) = f returns a sequence of the fields defined (and 
inherited by) class C; 

2. Mb(3Z,Q, m) = (x,e) returns the body e of the method m 
in class C, along with a sequence containing the names of its 
formal parameters; 

3. JT{£C, C,f) = D returns the type of field / in class C; 

4. MT{EC,C, m) = C — > D returns the signature of method m 
in class C. 

We explicitly define the lookup functions such that the class Ob j e ct 
is empty (i.e. contains no fields or methods). This is safe since 
the grammar of pFi precludes the existence of a user-defined class 
called Object. An execution context induces a standard subtype 
relation <: defined as the transitive closure of the of class exten- 
sion. 

A number of notions and concepts are defined that strongly de- 
pend on the current execution context (like reduction, type assign- 
ment, and predicate assignment), and which, therefore, should all 
be subscripted with its name; but since this context is not changed 
by execution, we will not do so. As usual, we impose some well- 
formedness conditions on execution contexts (e.g. all classes must 
be uniquely named, and the class hierarhy must be acyclic), (i) all 
classes are uniquely named; (ii) the class hierarchy is acyclic; (Hi) no 
class declares a field which it also inherits; (iv) if a class declares 



(newC(e„))./, -> e ; , T(SC,C) = f n &cien; 

(new C(e„))./ ; = ej -> new C(ei, . . . ,ejj, . . . ,e„ ), J"(£C, C) = /„ & i 6 n; 

(newC(e)).m(e'„) -5- e[ef/x n , new C(e) /this], Mb(EC,C,m) = (x n ,e). 

Figure 1: Reduction rules 

[ T " ASS 1 1 "TF77^7^~ t^'D'/HC) [T-NULL] : r| _ null . c (Cvriidinff) [T- VAR] : f h *:C (* :Cer ) 

. The:D r ,11-6:0 r h e,:C,' (Vi £ w) 

[ T " FLD ] 1 y I (JT(CD,/) = C) T-INVK : — — — (W(C,C,«) = C„ ->D) 

1 r e./l 1 h e.m(e n ):D 

, , rhe:C r , rhe;:C; (Vi6n) 

T-SUB : (C ' < :C ) T-NEW : — C,C = /„ & FT E,C,/j = Q (Vien)) 

r h e:C r h newC(e„):C 

Figure 2: Type assignment rules 



a method which it also inherits, then the declared signature must 
match that of the inherited method; (v) the variable this is not 
used as a formal parameter to any method; (vi) the types declared 
for fields and in method signatures must correspond to valid classes, 
as must all classes that are inherited from. Notice that in well- 
formed execution contexts we explicitly forbid the redeclaration of 
an inherited field, but we allow methods declared higher up in the 
inheritance hierarchy to be overridden (redefined) in a subclass, 
subject to the condition that the type signature is identical. Such 
behaviour is a common (perhaps even integral) aspect of the object 
oriented paradigm and is also present in FJ. 

2.1 Reduction 

We retain the permissive reduction of FJ (rather than restrict it 
to a call-by-value semantics as in other extensions, e.g. II II) an d 
extend it to handle field assignment. As in FJ, we use e[e' / x n ] 
to denote the expression obtained by replacing any occurrences of 
the variables X\ , ... , x n in e by the expressions ej, ... , e„ respec- 
tively. Formally, a reduction relation — is induced for each exe- 
cution context; however, as mentioned previously, from now on we 
will assume a fixed execution context. 

Definition 4. (pFJ REDUCTION) The one-step reduction relation 
is defined as the contextual closure of the rules given in FigureQ] 

2.2 Type System 

The types of pFJ are the same as those of FJ; that is, they are 
induced by the set of classes defined in the execution context, aug- 
mented with Object. We modify the type system of FJ to handle 
our extra syntax in an obvious way: we introduce extra rules to al- 
low null to be assigned any valid type, and ensure that the r- value 
in a field assignment expression has the expected type. We also 
introduce a separate subsumption rule. 

Definition 5. 1 . If a class C is defined in an execution context 
EC, then we say it is valid in EC; Object is valid in any 
execution context. 

2. A type environment is a set of statements of the form x.C, 
which is well formed when each statement refers to a uniquely 
named variable x and a valid type C. 

3. The typing judgement of pFJ is written as T h e:C - where 
T and EC are well formed - which reads: e has type C in the 
type environment T. The rules of the type assignment system 
are given in Figure[2] 



4. An execution context is type consistent if and only if the ex- 
ecution context is well formed and the body of each method 
can be assigned its declared return type under the type as- 
sumptions given for its parameters in the method signature. 

As for FJ, we can show a soundness result for pFJ: 

THEOREM 1. For type consistent execution contexts if T h e:C 
and e — > e' then T h e':C 

3. THE PREDICATE SYSTEM 

We now come to describe the first contribution of our work: the 
predicate system. Our system aims to provide an analysis which is 
more expressive than the simple type system of FJ: rather than sim- 
ply guaranteeing global properties of programs, we wish our predi- 
cate types to be semantic in nature, and capture runtime properties. 
We consider the behaviour of an expression (or rather, the object 
to which the expression evaluates) in terms of the operations that 
we may perform on it, i.e. accessing a field or invoking a method. 
We follow in the tradition of intersection types, originally defined 
as sequences [16], however, by treating our predicates as such: a 
predicate is a sequence of (potentially incomparable) behaviours, 
from which any specific one can be selected for an expression as 
demanded by to the context in which it appears. We also incorpo- 
rate the late typing of self, another important feature found in other 
intersection type systems for object calculi |8 5 |. This allows for 
a greater flexibility in the system, permitting us to update an object 
prior to invoking a method on it. 

We begin by defining our predicate types. 

Definition 6. (PREDICATES) Predicates are defined by the fol- 
lowing grammar: 



predicates : 


<p :: 


= T 


\v 


normal predicates : 


v :: 


= 91 


Lr 


object predicates : 


a :: 


= (i 


r) 


member predicates : 


t :: 







where the meta- variable £ ranges over the set of both field identi- 
fiers and method names. 

Object predicates thus comprise a sequence of statements de- 
scribing the behaviour of an object. Each statement associates a 
certain behaviour (described by the member predicate t) with the 
result of accessing the field or invoking the method labelled I. In 
the case of methods, the predicate additionally indicates the re- 
quired behaviour of the receiver (xp) and the arguments (cp). By 



fp-NTITll- (Cvalidinff) [p-VAP.1- fl:C:V6ll) 

[P NULL] . n p null . C:9 , V > [P VARj . n| _ X;C:1/ V > 

nhnewC(l):C . , nhe:D:(f:i/) 

P-NEWO : — —- — P-FLD : (FT(8Z,T>,f) = C) 

1 1 n h newC(e):C: {> 1 1 nhe./:C:v ' 

, ^ IThe:C':i/ r , n h e:C 

[P-SUBTJ : (C ' < : c & v e £(C)) 



n h e:C:v ' II h e:C : T 

. , II h e:C : ff{ (Vi E 5T) . , n h e:C : </ 

P-JOIN : ' v '-(»>o) p-seq : _^ (tr'sg^e^c)) 

n h e:C: U a„ n h e:C:u 

, nhe:C:u IIhe':D:v . , n h e:C : (TTt„) II h e':D 

[P " ASSl] : nh,/. 8 ':C:(/:>) (^C/)=D) [P-ASS 2 ] : __ 7 __^ (/ „ & ^c,/) = D , 

, n h e:D: (m :ii> :: ?„ -> v) nhe:D:ili n h e,:C; : d>: NiEn) 

P-INVK : 5 ^~ 7—^- ^ {MT(S.O,m) = C„ ->C) 

EI h e.m(e„):C : 1/ 

nhe;:C;:v n h e,:C, (Vi G TT 

[P-NEWF] : -j2 . - /( ^(^(ff,c)=/„&/e7r&V/e7T[JT(a;,c,/ 1 )=c,] ) 

1 ' n h new C(e„):C : (/■ : V) 

nhnewC(e):C n'he :D:v ^ . 

P-NEWM : — ■ = (CMTW r C,m) = C„^D&Mb (£,C,») = (i„,e ) &n' = {x:C:*„,thlS:C:lf})) 

n I- newC(t):C: (m:ip :: <p n ->v) 

Figure 3: Predicate Assignment Rules 



combining the predicate 9t (denoting a null value) with the object 
predicates we obtain the set of normal predicates, so called because 
they can be assigned to expressions which evaluate to safe normal 
formal The predicate constant T (top) is a standard feature taken 
from the intersection type discipline, and has the role of covering 
expressions which do not terminate or, more generally, the result 
of which bears no relevance to the running of the program in that it 
does not influence the final outcome. Notice that intersections are 
implicitly present in the object predicates, since there is no restric- 
tion in place on the labels used: a label can occur more than once. 
This corresponds to the approach of the strict intersection system 
® 

We now define a subpredicate relation and an operation which 
combines (object) predicates together. At the heart of intersection 
type assignment lies the ability to introduce an intersection of types 
and select a single type from an intersection. In our system the join 
operation facilitates the former (intersection introduction), and the 
subpredicate relation allows us to perform intersection elimination. 

Definition 7. (SUBPREDICATE RELATION) The relation ^ is de- 
fined as the least pre-order on predicates such that: 

91 «3 T V; en [(£??„) s3 (tm)} 

() «3 T VieW|>< (4:Tj)] => a^(eTz n ) (n > 0) 

Again, this corresponds to the type inclusion relation for strict types. 

Definition 8. (PREDICATE JOIN) The join operation is defined 
on object predicates as follows: 

(£t) U (F^r 7 ) = (1^ ■ Tv?) 

We generalise the join operation to sequences of object predicates 
as follows: 

U e = ( ) Uu -a = aU(Ua) 

Since the motivating idea behind predicates is to make a state- 
ment on the execution of an expression, we define the notion of a 
predicate language which allows our system to be truly predictive. 

2 The normal forms are safe in the sense that they do not contain 
null pointer dereferences. 



For example, by defining this notion, we can show that if we derive 
the predicate (/ : v) for a typed expression e:C, then the field / will 
be visible in the class C. Moreover, it will be safe to access the field 
in e, and the result will satisfy the predicate v. 

Definition 9. (PREDICATE LANGUAGE) £(C), the language of 
class C is the smallest set of predicates satisfying the following 
conditions: 

1. T 6 £(C), % e £(C) and () 6 £(C). 

2. 7T(£C,C,/) = D (ve£(D) <^ (f:v) e£(C)). 

3. MT(£C,C,m) = C„ ->• D <3> 

(V>e£(C) &Vi'en[0,e£(c,)] &ve£(D) & 
(m:ip ::|„ -)■!/) 6 £(C)). 

4. Vi 6 n[a l e £(C)] U a„ 6 £(C). 

This notion of language plays a crucial role in the approximation 
result that is presented in the next section. 

Definition 10. The rules for our predicate assignment system are 
given in Figure [3] A predicate environment II, which is a set 
of statements x:C:(p, is well formed if each statement refers to a 
unique variable x, a valid type C, and a predicate <p £ £(C). The 
judgement II h e:C : <p - where again IT and EC are well formed - 
asserts that the expression e of type C can be assigned the predicate 
(p using n. 

Some rules are premised by type assignment judgements, which 
we write using predicate environments instead of type environ- 
ments (II h e:C). Notice that this is more than a simple notational 
convenience: formally this is a sound extension since each type 
environment corresponds to a predicate environment in which the 
predicate information has been discarded. 

We can see the predicate system as a Hoare-style system of pre- 
and post-conditions. For example, the rule (p-FLd) expresses that 
if the expression e satisfies the predicate (/: v), then accessing the 
field / will satisfy v, giving an annotation like 

:: pre : e satisfies (/: v) 
e.f 

: : post : V 



p = T,9c,()=> Comp(Yl,e:C,p) <^ Apprcc(Jl,e:C,p) 

nhe:C&JT(ff,C,/)=D=» (Comp(U,e:C, {/: v)) & Camp(U,e.fiD,v)) 

nhe:C&MT(ff,C,m) = C„^D^ (Comp(Yl,e:C,{m:ip ::^„-5-v)) ^ 

(Comp(rLe:C,t/>) & Mien [ Comp(n,e,:C ; -,^,) ] => Comp(Yl,e.m(e„):D,v))) 
Mien [Comp(n,e:C,<Ji) ] ^ Comp(Yl,e:C, U a n ) (n > 0) 

Figure 4: Computability predicate 



As a final comment, we return to the issue of late self typing, 
mentioned earlier in this section. Notice that a method predicate 
{tn : ip :: cp — > v) is derived only for new object expression^] using 
the (P-NEWM) rule, and that no information about this object (save 
for its type, which allows us to look up the correct method body) 
is used to derive the self predicate ip. It is only at the point of 
invocation that we check the receiver to ensure it satisfies xp. This 
approach differs from the type systems of (TJ for the ^-calculus, 
where the self reference in the body of a method may only be given 
a type reflecting the current state of the receiver, even though it 
may be updated later. 

We now present the main results of the predicate system. 

Theorem 2. 1. 3 cp [ Yl h e:C:cp ] <^ Yl h e:C. 

2. Yl\- e:C:cp ^ cpeC(C). 

3. For type consistent execution contexts if Yl h e:C :cp and 
e — > e' then Yl h e':C:<p. 

4. APPROXIMANTS FOR p fj 

In this section, we derive an approximation result which can be 
used as a basis for semantics-based abstract interpretation, or, more 
directly, a termination analysis of pFJ. It also opens the way for- 
ward for giving a denotational semantics to our calculus. 

The notion of approximant was first introduced for the A-calculus 
by C. Wadsworth 1 39 1. Intuitively, an approximant can be seen as a 
'snapshot' of a computation, constructed by covering places where 
computation (reduction) may still take place with the element ffl 

Definition 11. We define approximate pFJ expressions by the 
following grammar: 

a ::= x | fi | null | a./ | a./ = a' | a.m(a) | new C(a) 

By extending the notion of reduction so that any field access, field 
assignment or method invocation on fi itself reduces to the expres- 
sion Q, we can also define the notion of approximate normal forms. 

Definition 12. Approximate normal forms are defined by the fol- 
lowing grammar: 

A ::= x | fi | null | new C(A) | 

A./ | A./ = A' I A.m(A) (A t fi, new C(A)) 

We extend the type and predicate assignment relations to operate 
over approximate expressions. We add a type assignment rule per- 
mitting Q to have any valid type, however we do not modify the 
predicate assignment rules. In particular, this means that fi must 
be assigned the predicate T. 

To formalise the notion of snapshot, we define an ordering on 
approximate expressions: 

3 This is not strictly true, since we might also derive a method pred- 
icate for a variable when it is mentioned in the environment. 
4 fi is the symbol originally used in [39|; more common now is to, 
as (9), use the symbol _L; since this could be confused with our 
predicate T, we have opted for the old notation. 



Definition 13. The direct approximation relation C over ap- 
proximate expressions is defined as the smallest pre-order satisfy- 
ing: 

fi C e 
eCe' ^ e.fQe'.f 
ej C ej & e2 C ej ei ./ = e2 E ./ = e' 2 
e C e' & e,- C for all z en e.m(e n ) C e'.m(e'„) _^ 

e; Q for all i en =3- new C(e„) C new C(e' n ) 

An approximant of an expression e is an approximate normal form 
A which directly approximates some expression e' to which e re- 
duces, except for occurrence of fi in A (so A C e')- We write .4(e) 
to denote the set of all the approximants of e. 

The following result gives an approximation semantics topFJ, in 
which we interpret an expression by its set of approximants, [feJJ = 
A(e). 

Lemma 1. e -+* e' => „4(e) = »4(e') 

As a shorthand notation, we define an approximation predicate: 

Definition 14. Appr £C {H,e:C,ip) 

nhe:C&3A6^(e) [nhA:C:<p]. 

The approximation result is the following: any expression to 
which a predicate can be assigned has an approximant with that 
same predicate. We follow Tait's proof method |38| involving a 
computability predicate. Space restrictions do not allow us to present 
the proofs in detail. 

Definition 15. (COMPUTABILITY PREDICATE) The computabil- 
ity predicate is defined inductively over predicates as in Figure [4] 

A key step in the proof is to show that computability implies ap- 
proximation: 

Lemma 2. 1. Comp(Yl,e:C,cp) => Appr^ (Yl,e:C,cp). 

2. n h x:C : (p => Comp(Yl, x:C, cp). 

The next step is to formulate a replacement lemma, which states 
that if we replace all the variables in a predicable expression with 
expressions computable of appropriate predicates, then we obtain a 
computable expression. 

Lemma 3 (Replacement Lemma). If n h e:C : (p, and 
there exists Yl', e' n such that for all xp.Cp.cpieYl we have that 
Comp(Yl' ,ep.Ci,cpi), then Comp(Yl' ,e[x/e n ]:C,<p). 

Given that all variables are computable of predicates which are 
assignable to them (Lemma|3, we can simply replace all the vari- 
ables in an expression by themselves, and so a corollary of the re- 
placement lemma is that if an expression can be assigned a predi- 
cate then it is also computable of that predicate. 

Corollary 1. Yl h e:C:cp =^ Comp(Yl,e:C,cp). 



Combining this with Lemma[2]allows us to derive our approxima- 
tion result: 

THEOREM 3. If 11 h e:C:cj) then there exists A 6 -4(e) such 
that II h k:C:<p. 

While the approximation result shown above is significant in its 
own right, perhaps of more interest is that it facilitates a termination 
analysis of pFJ. We can show that all expressions to which we can 
assign a normal predicate (i.e. not T) have a head-normal form, 
that is they will reduce to either the null value or an objecQ. 

Definition 16. (HEAD NORMAL FORMS) Head normal forms for 
pFJ are defined by the following grammar: 

H ::= x | null | newC(e) | 

H.f | H.f = e | H.m(e) (H * null,new C(e)) 

Theorem 4 (Termination), fllh e:C:v then there ex- 
ists H such that e — >■* H. 

To illustrate this result, consider the following program: 

Example 1. Take the environment 

class C extends Object { 
C f 

C m() { this . f } 

} 

Notice that the expression (new C (null) ) .m() has the ap- 
proximant null (which is also its normal form). We can easily 
derive h null:C:9t using the (P-NULL) rule. The following 
derivation shows that we can also assign this predicate to the origi- 
nal expression: 



0h null:C:SR 

h n ew C (null) :C: (f:9i) 

{this:C:(f:9t)} I" this:C : (f :9t) \ 
{this:C:(f:9i)} h this.f:C:9t \ 
0hnew C (null) :C : (m:{f:9i) :: e 9i) : 
h (new C (null) ) .m( ) :C:9t 

5. WHAT ABOUT COMPLETENESS? 

While the system we have presented in this paper is sound (ex- 
hibits subject reduction), it is not completely expressive since pred- 
icable approximants may exist for an expression to which we can- 
not assign those same predicates. This is a consequence of the fact 
that our system does not have a subject expansion property (as other 
intersection type assignment systems do). While this may easily be 
achieved by discarding our notion of predicate language, doing so 
would destroy the semantic underpinning of our system (i.e. the 
approximation result). The challenge, therefore, is to construct a 
system with both properties. While we do not offer a comprehen- 
sive solution here, we will discuss the underlying reasons for the 
failure of subject expansion in the presence of predicate languages 
as we have defined them, and discuss, at an abstract level, the steps 
that will be required. 

This issue goes right to the heart of the object oriented paradigm 
since the failure of subject expansion in our system lies in the dy- 
namic dispatch feature of OO. 

5 This holds for expressions typed in an empty environment (closed 
expressions). In general, a head normal form may also comprise a 
sequence of field accesses, assignment and method invocations on 
variables. 



Example 2. Take the program 

class Sub extends Object { 
A upcast (Ax) { x } 

} 

class A extends Object { 
A m() { this } 

} 

class B extends A { 
A f 

A m() { this.f } 

} 

and the run 

(new Sub()).upcast(new B(new A ( ) ) ) . m ( ) (1) 
-> (new B (new A ( ) ) ) . m ( ) (2) 
-» (new B(new A() ) ) . f (3) 
— > new A() (4) 

We begin by invoking the method m on the receiving expres- 
sion (new Sub ( ) ) . upcast (new B (new A ( ) ) ) . By look- 
ing at the execution context, we see that the upcast method re- 
turns a result of type A. However, at runtime, the result is actu- 
ally an object of type B, namely new B (new A ( ) ) . Thus, the 
method body that will be executed when m ( ) is invoked will the 
one found in class B. So, are we able to derive a predicate for 
(new Sub ()). upcast (new B(new A())) that will allow 
the call to m ( ) be typed? 

In order to do this, we must find a predicate (assignable to the 
object new Sub ( ) ) for the upcast ( ) method such that the re- 
sult is the predicate mentioning m that we desire. This will be of the 
form (upcast:)/? :: V — > v) since the upcast method simply re- 
turns its argument. However, in addition to v mentioning m, it must 
be the case that both v E C(a) and Yl h new B(new A()):A:v. 
Here we come to heart of the matter: in order to derive a predicate 
describing the method m which we can assign to new B ( new A ( ) ) , 
we must look at the body of m in B . This method body refers to the 
field f in the receiver (this), and thus any predicate which we 
derive must also mention f . However, since f is not visible in the 
type A any such predicate will not be in the language of A. We find 
that there is no predicate v which satisfies the necessary criteria and 
so we will not be able to assign a (non-trivial) predicate to expres- 
sion (1) even though we can do so for its normal form, expression 
(4): e.g. h new A ( ) :A : { ) by using rule (P-NEWO). 

Given that predicate languages are an essential element for the 
predictive abilities that we desire, the solution to the expansion 
problem will have to consist in modifying the definition of pred- 
icate languages to make them more permissive. In the example dis- 
cussed above, we required a predicate to mention members which 
were not visible in the class of the language to which it belonged. 
Clearly, we must be able to allow predicates to contain such infor- 
mation, but only in the cases where it is necessary for expansion 
to hold since we still require that predicate languages make a state- 
ment about what is visible in a class and what is not. 

6. CONCLUSIONS AND FUTURE WORK 

We have presented a predicate (type) system for pFJ, a variant 
of FJ, and shown that our predicates describe semantic properties 
of expressions. Our system thus has more expressive power than 
traditional type systems for Java. We see our results as important 
initial steps along the road to building not only semantic models for 
object oriented programming, but also practical analytic systems. 
A key development towards this aim will be to extend our system 
to a stateful programming model, akin to Middleweight Java 1121 . 



Another objective of immediate concern to us is that of addressing 
the issues discussed in ij5]and achieving subject expansion. 
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